Night Owl 9/Night Owl CD-ROM (NOPV9) (Night Owl Publisher) (1993).ISO/051a/vl6_068.zip/VL6-068.TXT

Internet Message Format | 1993-04-22 | 55KB

From lehigh.edu!virus-l  Wed Apr 21 13:40:10 1993 remote from vhc
Received: by vhc.se (1.65/waf)
    via UUCP; Thu, 22 Apr 93 00:49:39 GMT
    for mikael
Received: from fidoii.CC.Lehigh.EDU by mail.swip.net (5.65c8-/1.2)
    id AA01091; Thu, 22 Apr 1993 00:45:13 +0200
Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA36918
  (5.67a/IDA-1.5 for <[e-mail]>); Wed, 21 Apr 1993 17:40:10 -0400
Date: Wed, 21 Apr 1993 17:40:10 -0400
Message-Id: <[e-mail]>
Comment: Virus Discussion List
Originator: [e-mail]
Errors-To: [e-mail]
Reply-To: <[e-mail]>
Sender: [e-mail]
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: VIRUS-L Digest V6 #68

VIRUS-L Digest   Wednesday, 21 Apr 1993    Volume 6 : Issue 68

Today's Topics:

Source of Virus Information
Re: Viruses and Canada
Re: Scanners getting bigger and slower
Re: Should viral tricks be publicized? (was: Integrity checking)
V-Sign? (PC)
Re: Can a virus infect NOVELL? (PC)
Re: Integrity Checking (PC)
Re: Censorship/40-Hex (PC)
Re: FORM-18 Virus and 1.44Mb diskettes (PC)
Re: Port Writes (PC)
Re: Unknown little virus? (PC)
Re: VSUM (PC)
Re: DOS 6.0 and Scan (McAfee) Interaction (PC)
On the merits of VSUM (PC)
Surviving warm boots (PC)
Re: Can a virus infect NOVELL? (PC)
Re: Proffesional Group Virusized ! (PC)
Re: ANSI viruses and things that go bump in the night (mostly PC)
BeBe Virus (PC)
"DIR" infection, or "Can internal commands infect" (PC)
"DIR" infection, or "Can internal commands infect" (PC)
"DIR" infection, or "Can internal commands infect" (PC)
Re: Single state machines and warm reboots (PC)
Re: DOS 6.0 and Scan (McAfee) Interaction (PC)
New files on risc (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  (The complete set of posting guidelines is available by
FTP on cert.org or upon request.) Please sign submissions with your
real name.  Send contributions to [e-mail].  Information on
accessing anti-virus, documentation, and back-issue archives is
distributed periodically on the list.  A FAQ (Frequently Asked
Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5).  Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<[e-mail]>.

   Ken van Wyk, [e-mail]

----------------------------------------------------------------------

Date:    Tue, 20 Apr 93 08:29:29 -0400
From:    Garry J Scobie Ext 3360 <[e-mail]>
Subject: Source of Virus Information

There has been a number of postings concering obtaining accurrate
information about PC viruses. Although not available by ftp (yes
you will have to put your hand in your pocket :-) I've found the
following to be most helpful.



Solomon, A. 1991    "PC Viruses. Detection, Analysis and Cure".
Springer-Verlag. London.

This book deals with around a hundred or so of the most common PC
viruses and has a number of interesting technical observations. Well
worth a read.


Solomon, A. 1992    "Dr Solomon's Virus Encyclopaedia". S & S
International Ltd. 2nd edition.


The Encyclopaedia comes with the Anti-Virus Toolkit. I do not know if
it can be purchased separately. It covers a large number of viruses
including many obscure ones. The opening pages also include an
excelent description on Stealth techniques.


Cheers

Garry Scobie LAN Support Officer Edinburgh University Computing
Services e-mail [e-mail]


------------------------------

Date:    Tue, 20 Apr 93 15:34:08 +0000
From:    [e-mail] (alan parker S)
Subject: Re: Viruses and Canada

    I'll try an clear up a few queries, arising from responses to the
previous posting.
    At this point in time, we as a university have experienced Stoned,
Noint, Manitoba and something which F-Prot 207 suggests is a Stoned variant,
and Scanv102 calls stoned.
    On scanning numerous student/faculty floppy disks we have noticed
that the disks which had system files on them, have the files no longer
hidden.  On getting information on the disk, via in this case Virus
Busters Doctor program, the disk label(always garbage), O.E.M IBM 3.3,
followed by the id is displayed.
    The 'stoned variant' which I refer to above, is called Manitoba by
Virus Buster 3.95, but with 3.94 this was not the case.  The main
differences(for us) between these two releases was that the program could
now remove 'Manitoba' from floppy disks.
    I've received comment from one of the writers of Untouchable, and
have forwarded additional testing information, however I'm still
re-assessing the untouchable software; however the original testing resulted
in the previous posting.
    To summarise, Untouchable 1.13 allowed us to restore from the safe
diskette after boot infection, on being infected with an unknown boot
infection the res part of the packages(UT and S&D) flagged a different in
available memory, 2K, since in the defining of the system original 640K was
listed, now 638 is available.  However no virus was detected, but suggestions
were made of a possible infection.
    As far as the form infection which was mentioned, the diskette in
question had been shipped from Germany, and the student was complaining of
'errors' on the disk.  On using f-prot the disk had Manitoba and form was
revealed as well.  On examining the disk attempting to restore the users
'critical' information, less and less of the disks contents were becoming
available to us, with each attempt.  However perchance the disk has a great
deal of physical damage, originally all but a few files were accessible to
the student via ordinary dos means.. such as type or indeed by using a
wordprocessor.  However again on repeated calls of the same file(s) more
data errors were flagged ending in general failures which resulted in the
disk being checked with Norton.
    On the untouchable theme, the copy we were supplied with for
evaluation, came as three seperate items, each of which we installed fully.
Untouchable 1.13, Search and Destroy, Untouchable NLM.
    I hope this goes some way to making the original post clearer.

    Alan


------------------------------

Date:    Tue, 20 Apr 93 16:37:59 -0500
From:    Jim Huguelet <[e-mail]>
Subject: Re: Scanners getting bigger and slower

In response to:

> Article 8697 of comp.virus:
> From: [e-mail] (Inbar Raz)
> Subject: Scanners getting bigger and slower
> Message-ID: <[e-mail]>
> Date: 8 Apr 93 23:20:13 GMT

[stuff deleted]

> Data Security. More than once I had a meeting with Bank representatives, and
> even a Hospital representative, which wanted to know more information. All of
> them came to a point where they said - "But what good is a SmartCard, if
> people can lose it just as well as they can lose/give away their password?"
>
> There is no reply to that. The human factor will always exist, and this is

[stuff deleted]

There is a reply, of sorts, because there is a not insignificant difference
between a password (or other "what you know" authentication schemes) and a
smart-card (and "what you have" authentication.)  Only one person can be
in possession of a smart-card at a given moment - many people can be in
possession of a password simultaneously.  Users cannot tell if their password
has been compromised, but they can determine whether or not they're still in
possession of their token.

===============================================================================

 Jim Huguelet                                    [e-mail]
 Department of Computer Science
 Psych-Math Building, Room 461                   Voice: [phone]
 Northern Illinois University
 DeKalb, IL  60115                               Opinions expressed are my own

------------------------------

Date:    Fri, 09 Apr 93 04:39:00 +0100
From:    [e-mail] (Sara Gordon)
Subject: Re: Should viral tricks be publicized? (was: Integrity checking)

[e-mail] (Vesselin Bontchev) writes:

>My experience shows me that the bad guys are less knowledgeable but
>better organized and learning faster than the good guys... And I am
>not excluding even us, when I am speaking about "better organized".

as someone who does study this, i am sorry to have to agree with you.
the organization of the 'bad guys' is really extraordinary considering
the usual problems of such organizational efforts...

>Yes. I am getting virus collections from all over the world. Do you
>know how many of them bear the signature of being downloaded from
>Todor Todorov's BBS?


but wait!! this does not necessarily mean they came from that bbs,
of course. i have viruses sent to me from all over the world that
have the names of anti-virus companies, anti-virus researchers, even
my OWN name...this does not mean they originated here. why, i even
have seen them from the VTC at Hamburg...i.e., when they are
unzipped, they say 'Virus Test Center, University of Hamburg' in
the A-V marking!

of course, viruses did come from that bbs in sofia. its fortunate
that bbs is no longer in operation; and unfortunate that many more
have taken its place, mainly in the USA....and no one seems to
care....

>Burger's and Ludwig's books are crap - they don't teach you anything,
>even how to write good viruses. They don't contain useful information,

i assume you meant to write viruses well, not to write good viruses :)

- - --
           #  "talk to me about computer viruses............"
           #  fax/voice:    219-277-8599     p.o. 11417 south bend, in 46624
           #  data          219-273-2431     [e-mail]
           #  fidomail      1:227/190        [e-mail]
- --- OD 0.0.1
 * Origin: C.C.C. (9:462/121.0@VirNet)

====> OverDose Gateway Notice <====
Message is actually from [e-mail]
Reply to 9:462/121.0 Internet Gateway with first line of message body beeing:
TO: [e-mail]

------------------------------

Date:    Tue, 20 Apr 93 10:50:25 -0400
From:    Barbara Carlson <[e-mail]>
Subject: V-Sign? (PC)

A computer in a public cluster here turned up with what f-prot called
"V-Sign". It said it infected the boot sectors of each of the drives
(c,d,e,f) and listed garbage as the name for one of them. Has anyone
heard of this virus? There is no mention of it in the listing that comes
with f-prot. The version of f-prot was current -- 2/93. They had to do a
hardware reformat of the disk - *three times* - could this thing have
stuck around and diverted a format? Anything out there that could get
rid of it??

- --Barb--



------------------------------

Date:    Tue, 20 Apr 93 16:44:21 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Can a virus infect NOVELL? (PC)

[e-mail] (Xianyow ) writes:

>    I have a question, can a virus infect NOVELL system?

Yes, of course. And it even happens relatively often. Mainly due to
sloppy LAN security.

> Since there are
> many read-only files in NOVELL, how can it write into that file?

Theoretically, it can't. However, what does exactly mean "read-only"?
A file with the ReadOnly -attribute- set? A virus could easily remove
this attribute, if the Modify -right- is granted to this file. Or do
you mean a file that does not have the Read -right- granted? Granted
to whom? If -you- do not have the right to write to this file, some
other user might have it. And this user's workstation might be
infected... Or even the supervisor's workstation might be infected -
it happens... And the supervisor is able to write to any file...

Similarly, it is possible to bypass the ExecuteOnly attribute by using
a companion virus, as described in Dr. Cohen's paper in the
proceedings of the 2nd Virus Bulletin conference. The paper describes
in details his experiments on how protection works (and how it
doesn't) on Novell NetWare and Unix file servers. Unfortunately, he
has used NetWare 3.11 in his experiments. This is a version we don't
have here, so we were unable to repeat the experiments. We did some
similar experiments on NetWare 2.15c, but found nothing exceptional,
except that if you establish a sloppy combination of rights and
attributes, a virus will be able to infect the files.

> If it can't
> , how can it live when the power turned off?

:-). It "lives" in the infected files. Whenever you execute one of
them, the virus becomes active. If it is a memory resident one, this
means that it installs itself in the memory of the workstation that
has executed the infected file.

>    But I really heard some viruses can infect NOVELL.  Can anyone answer me?

Yes, many of the existing viruses do - if the protection settings
allow (or do not forbid) them to do so and if the viruses are written
well enough. There are also a few NetWare-aware viruses that steal
passwords.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

------------------------------

Date:    Tue, 20 Apr 93 16:55:37 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Integrity Checking (PC)

[e-mail] writes:

> I am looking for a program like Integrity Master that will store all the
> data in one file.  I dislike Integrity Master because it stores all the
> info in each subdirectory.
> At the same time I would like something as safe or safer than Integrity
> Master.

You didn't specify it to be shareware, did you? OK, there is a
commercial product that does that - it is called Untouchable and is
marketed in the USA by Fifth Generation Systems.

Actually, there are many other products that use only a single
database of checksums - NAV, SCAN, Sentry, Dr. Solomon's AVTK, etc.,
but since you also wanted it to be secure...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

------------------------------

Date:    Tue, 20 Apr 93 13:02:37 -0400
From:    [e-mail]
Subject: Re: Censorship/40-Hex (PC)

David Hanson, <[e-mail]>, wrote:
> And how does a "good guy" get 40-Hex?  ...

Chance.

> ... Wouldn't receipt of 40-Hex from
> *any* source be participation in the -distribution- of this magazine?
> Not necessarily by dissemenating the info ("good guys" would NEVER do
> that), but by creating demand.  ...

I don't solicit for such material.  If it happens my way and tells me
what is 'popular' with the virus writers, I am quite happy to take this
as a hint to what I should be doing in response.

> ... Even if you get it from another "good guy",
> passing the magazine from one place or person to another is distribution.
> This is something that is ok for YOU to participate in, but not ME (if I am
> to be a "good guy")???

Viruses are going to remain a problem for the forseeable future.  So
the publicity and 'glamour' associated with producing will assure they
continued production.  Maintaining 'virus scanners' is expensive in time
and labour,


> Tell me, where do YOU get 40-Hex from?

Generally other researchers say "the new issue of 40-hex includes a new
virus/advocates method X of attacking a-v products" and pass me a copy.
I can then revise my a-v tools to ensure that I can help my clients when
these viruses are spread.

> Why should it be ok for you to receive it, but not me?

40-hex is basically an incitement to write and distribute viruses, with
hex dumps and disassemblies, and a few words of editorial encouragement.
As such it is quite dangerous, a barely competent PC user could follow
the published instructions to obtain an active virus.  I wouldn't sell
a gun/car/tank of acid to someone unless I am persauded they are
competent to own/handle it.  Similarly I will not pass something as
damaging as a virus unless you persaude me that you are competent to
handle, store and keep it safe.  I should mention that I take a lot of
persauding.


> I do not wish to detract from the extremely valuable and "good" work that
> you do as a virus researcher, just want to point out that "good"/"bad"
> is not black/white, more like shades of gray.  Case in point - your
> participation in 40-Hex distribution.  If you're going to fight the "bad"
> guys, you've got to get your hands dirty.

This is utterly wrong, there is no need to "get my hands dirty".  If I
obtain useful insight into virus writers current objectives it is
curteous of me to alert other virus researchers.  In the case of 40-hex
it is simplest to forward the whole publication.


> BOTTOM LINE:  I really get peeved when access to information such as
>               40-Hex is limited "for my own good".  ...

It is not for your good, but mine.  It is unethical for me to pass such
material to someone who might use it malicously, or is likely to have
an 'accident' because they are not competent to take adequate safeguards.

>               ...  In the short term,
>               censorship may seem like a good idea, but in the long term,

It's not censorship, but trust.

I work hard to earn the trust of my clients, and other researchers.
I intend to keep that trust by behaving ethically, and being exceedingly
cautious in providing viruses to other people.

Regards,
- --
Anthony Naggs                 Email:                  Paper mail:
 Software/Electronics Engineer [e-mail]    P O Box 1080, Peacehaven
 & Computer Virus Researcher   or [e-mail]   East Sussex  BN10 8PZ
 Phone: [phone]         or [e-mail]     Great Britain


------------------------------

Date:    Tue, 20 Apr 93 13:25:24 -0400
From:    [e-mail]
Subject: Re: FORM-18 Virus and 1.44Mb diskettes (PC)

Paul Ferguson, <[e-mail]>, wrote:

> Recently. however, this particular variant surfaced again
> yesterday. I made sure that I got a functional copy this time.
> This variant activates on the 18th of the month, as described in the
> dialog below from last fall.

Hi Paul

I don't remember looking at this one, probably sitting in my "in-tray"
still, :-)

> On a 1.44 Mb diskette, FORM relocates it's "jump" code to Cyl 7,
> Side 0, Sector 16. It relocates the original DBR in the next sector,
> sector 17, and marks both sectors bad. The text contained in sector
> 16 is the same "The FORM Virus sends greetings..." message as with
> the original FORM.
>
> Correct me if I'm wrong, but isn't this area used by DOS to store the
> second copy of the FAT? If my understanding is correct, then the disk
> allocation for a 1.44 Mb diskette is:
>
> Sectors        Used for         Used by
> - -------        --------         --------
>   0            Boot Record        DOS
>  1-9           1st FAT            DOS
> 10-18          2nd FAT            DOS
> 19-32          Root Directory     DOS
> 33-2,879       Data               Whatever

I think you're suffering from a summer cold, you did say cylinder 7!

If Cyl 7 Side 0 Sectors 16, 17 are the physical address, on a 1.44Mb floppy
these translate to 'absolute' DOS sectors 267 & 268, (clusters 236 & 237).
Quite a long way from the FAT.

Hope you don't feel too foolish.  Good luck with Legal Net Monthly, the
first issue certainly looks promising.

Regards,
Anthony Naggs                 Email:                  Paper mail:
 Software/Electronics Engineer [e-mail]    P O Box 1080, Peacehaven
 & Computer Virus Researcher   or [e-mail]   East Sussex  BN10 8PZ
 Phone: [phone]         or [e-mail]     Great Britain


------------------------------

Date:    Tue, 20 Apr 93 16:59:00 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Port Writes (PC)

[e-mail] (Amir Netiv) writes:

> What do you mean "non-natural way" who said that the "natural way to write to

> a disk is only via INT-13, and how do you think INT-13 accesses the disk? Why

> can't it be by port write? Does the DMA not use ports to perform some disk
> transfers? I'd say that generally your suggested method is good due to the
> lack of other methods (except hardware products that monitor the system-bus)
> but I don't think it is suitable for implementation in a software product
> because you'll have more False Alarms then you can handle (at probably the
> worst times).

By a natural way to write to the disk I mean - using the DOS file
system. After all, all DOS manuals are telling you that this is the
way to write to the disk. Internally DOS translates this to INT 13h
requests. You could also use INT 26h (which is also translated to INT
13h requests by DOS, but DOS never uses INT 26h itself), or even INT
13h yourself, but this is already considered "dangerous" by any kind
of resident interrupt monitoring program I have ever seen. The only
programs that usually go that low are the programs from the Norton
Utilities and the similar packages - disk organizers, directory
sorters, disk editors. Oh, yes, and CHKDSK uses INT 26h too - when it
needs to fix the FAT(s).

Regarding the DMA, the abbreviation stands for Direct Memory Access
and, as the name suggests, is used to access the memory in a fast way
(bypassing the CPU) - not the disk. Of course, it is possible to do
very fast disk transfer by controlling the disk via the ports and
initializing DMA transfer to copy the read data to the appropriate
location.

At last, regarding what you think - whether the implementation will be
suitable or not - I am not talking theories here. I have actually used
such a product for months - and it never gave a false positive, and
never allowed a virus to write to my hard disk. Maybe I was just lucky
and didn't use some of the programs you claim to cause false positives
if such a protection scheme is used. Could you name some particular
products?

Oh yes - why I am not using the product any more. Well, the Dark
Avenger wrote the Number of the Beast viruses, and the Phoenix
viruses, and the two guys from Varna wrote the MG viruses. All those
viruses don't try to bypass INT 13h - instead they intercept it at two
levels and fake a read when they want to do a write - so our nice
protection program sees a read request, tells the "device ready"
watching program "it's OK, buddy, let it pass", but here comes the
virus again and turns the request back to write... If you are an
anti-virus researcher worth your salt, you should be able to
understand what I am talking about by looking at the viruses I
mentioned...

> Again, if you interfere in the wrong time, you might end up with a crashed
> disk. But theoretically it is true.

As I wrote about, I am not talking "theoretically" here. It is
practical, it does work, I used a product that relied on this scheme
(and did a lot of other things, like providing a Cyrillic keyboard
driver, switching the character generators of the Bulgarian IBM PC
clones, displaying a clock and the status of the *Lock keys on the
26th line of the screen on CGA controllers), and it NEVER crashed my
disk. The only reason I stopped using it was because there appeared
viruses that were able to circumvent it and I hate to be given a false
sense of security. Well, yes, and I switched to EGA/VGA, but I also
switched to a different clock program which is still able to display a
clock on the 26th line... and the other bonuses too... :-)

>  > BTW, note that many hardware anti-virus products - will-
> *MIGHT* instead of "- will -" ;-)

>  > be able to
>  > stop this kind of disk access, if they can be installed between the
>  > computer and the disk controller or between the disk controller and
>  > the bus...

Please, don't quote me out-of-contest - I specified when some hardware
anti-virus tools WILL and I mean will be able to stop this kind of
disk access. I am not claiming that all of them do it - just that
those of them that can do it WILL do it.

> Usually the Hardware Anti-Virus products are installed ON the system-bus (in

Some are, some are not. Here are some examples - ThunderByte -can- be
installed between the controller and the hard disk. ExVira -is-
installed between the controlled and the bus. Where are your examples?

> one of the slots), if one does as you suggest (between disk and bus) I'd
> expect "some"  8-) problems (to say the least).

You'd expect? Then you'd expect wrong - as I said, ExVira is installed
exactly in this way. In practice, you plug the card in a free slot,
there is a flat cable that ends with something that resembles to a
piece of paper, metalized from one of the sides only. You put it in
the slot where the disk controller normally resides with the
non-metalized side down. It is flexible and fits in the slot. You then
insert the disk controller atop of it. The signals go to the
controller, from it to the ExVira card. The card is a whole computer,
with 68000 CPU, lots of RAM, ROM, and is attached not only to the hard
disk controller, but also to the keyboard.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

------------------------------

Date:    Tue, 20 Apr 93 17:27:37 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Unknown little virus? (PC)

[e-mail] (Malte Eppert) writes:

>  > There's no way to fit a memory-resident virus into 32 bytes...

> What about a resident 'high DOS' or XMS swap routine, could it be that short?

Well, dunno, what do you mean exactly by that? A big high-loaded TSR
that has a small routine in conventional memory to call it? Dunno...
maybe; have to check.

Actually, I am no longer so sure about my initial statement. Padgett
demonstrated me how it is possible to make the resident part of the
virus occupy just 35 bytes. It is trivial to extend his idea into a
program that consists of 31+4 bytes - that is, 31 consecutive bytes in
one place and 4 consecutive bytes anywhere else - DOS is full of
holes...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

------------------------------

Date:    Tue, 20 Apr 93 17:32:53 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: VSUM (PC)

[e-mail] (007) writes:

> >What do you recommend as a better alternative, instead of VSUM then?

> So far the best source of CORRECT information has been from Frisk's
> F-prot.  I have yet to find a case where his information has been incorrect.
> Unfortunately, there isn't a whole lot of info included.

Yes, that's the problem. All existing sources of such information are
either incorrect, or incomplete, or both... :-(

> The sort of info I'd like is on the order of: if resident, how?  What
> interrupts are hooked?  Does it ask DOS to allocate memory, or does it
> go around DOS?  If it's buggy, why?

Ah, yes, you are reminding me of something. We have such a project in
CARO. Exactly what you would like a database of technical virus
information (no scan strings, sorry) in a highly tokenized format -
so that it permits easy searching and report generation. It's only the
information skeleton - you can build a front end that uses the
information to generate human language descriptions which could be as
verbose as VSUM's entries, or just view it as database records with
some mnemonic expansion of the values of the fields - if you are
knowledgeable enough to understand them.

The format is ready, we also have a few virus descriptions that
illustrate how to use it. They are free for distribution or inclusion
in any products (commercial or not). However, the copyright is
retained by the University of Hamburg and you are not allowed to
modify the entries without our permission. The people who write each
entry have a copyright on it, but are granting it to the University
(at least this is what I understood; I am by no means competent in
these matters).

What you are reminding me is that I have to make this information
available by anonymous ftp. It will be accessible as

ftp.informatik.uni-hamburg.de:/pub/virus/texts/carobase/carobase.zip

Please, note that this is not a source of information about viruses -
at least not yet. It is practically empty. The important stuff is the
format of the database. The database itself is expected to be created
later.

> names of the analysts on the information.  With so many people dissecting
> viruses, if we all pooled our knowledge we could get an info sheet of enormou
s
> proportions!

Yes, that was the intent - that the virus experts are filling the
database in the designed format.

> Oh, well.  Enough dreaming. ;->

Why dreaming? Get the format and begin sending us entries!... :-)

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

------------------------------

Date:    Tue, 20 Apr 93 17:54:23 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: DOS 6.0 and Scan (McAfee) Interaction (PC)

[e-mail] (Donald Gingrich) writes:

> 1. he booted the machine with the MS DOS 6.0 VSAFE in the autoexec (config?)
>    (I haven't seen DOS 6.0 yet)
> 2. he ran McAfee scan with the /chkhi option twice (don't ask why)
> 3. on the second pass it reported the "filler" virus
> 4. he has scanned the hard disk with the /chkhi /a options after a cold boot
>    on a known clean floppy -- nothing found

> seems like a false positive to me.

Hmm, sorry I was unable to reproduce the problem. First, SCAN 102 does
not scan the memory twice, even if you supply the /chkhi option twice.
Second, it didn't find any viruses in memory, even with VSAFE loaded.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

------------------------------

Date:    Tue, 20 Apr 93 18:00:08 -0400
From:    Mikael Larsson <[e-mail]>
Subject: On the merits of VSUM (PC)

 007 <[e-mail]> writes:

> Isn't there enough misinformation out there already?  Of course VSUM will
> be fine for the "common-people"-- they don't know any better!  I find it
> very upsetting that you would be willing to knowingly spread information
> that is just plain WRONG.  You are preying on the ignorance of these
> common people.

No, that is not correct, but since most of the common-users get infected
by viruses like form, cascade etc.. and wants to read about THOSE
viruses, then I think VSUM is good.

> It is one thing to be wrong, admit you were wrong, and correct any mistakes
> possible, and entirely another to be wrong, know you are wrong, and just
> not care that many people will have just enough information to get into
> trouble.  Ignorance, at least, inspires caution.

Sure, there are incorrect info in VSUM, but the users get the general
idea of what the virus does/does not. The COMMON user aren't interested
in all the technical stuff about that virus that they got infected by,
they wanna see if it does any harm or not, how it spreads.


Hope you get my point,

MiL

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Virus Help Centre     Phone:  [phone]   Email: [e-mail]
Box 7018              Fax:    [phone]   or   : [e-mail]
S-811 07  Sandviken   BBS #1: [phone]   Fido : 2:205/204 & 2:205/234
Sweden                BBS #2: [phone]   Authorized McAfee Agent!


------------------------------

Date:    Tue, 20 Apr 93 19:35:23 -0400
From:    [e-mail]
Subject: Surviving warm boots (PC)

A. Padgett Peterson, <[e-mail]>, wrote:
> ... Accordingly the following code is presented as
> an explicit way to generate a warm reboot that would be difficult
> (but not impossible - this is software after all but a virus would have
> to be looking for this specific sequence) to intercept (and there is a very
> large number of ways to express the same thing).
>
> ...

    This is indeed a (fairly) reliable method of resetting a PC.

A word of WARNING:
    This is flawed, in that it can potentially cause data damage to your
    PC.  Expanded Memory Managers, Disk Caches and other software often
    need to be warned of a reset, in order to reset hardware and empty
    write buffers.  I think the FAQ for comp.os.msdos.programmer has the
    appropriate information if you want to write a safe system reset
    program.  (OTOH warning other software of the reset effectively defeats
    trying to reset without allowing resident viruses to interfer.


Regards,
Anthony Naggs                 Email:                  Paper mail:
 Software/Electronics Engineer [e-mail]    P O Box 1080, Peacehaven
 & Computer Virus Researcher   or [e-mail]   East Sussex  BN10 8PZ
 Phone: [phone]         or [e-mail]     Great Britain


------------------------------

Date:    Tue, 20 Apr 93 20:19:23 -0400
From:    [e-mail] (Kam Bansal)
Subject: Re: Can a virus infect NOVELL? (PC)

>   I have a question, can a virus infect NOVELL system?  Since there are
>many read-only files in NOVELL, how can it write into that file?  If it can't
>, how can it live when the power turned off?
>   But I really heard some viruses can infect NOVELL.  Can anyone answer me?

If the server is setup correctly (trustee rights etc), all should be well (
famousee last words!). Novell is really good at stopping anything from
changing a file that is read-only or the user only has read only rights. I'
ve tried along time to smash it, and lost! There is a command in netware 3.x
that goes something like this

    "set executable files read only = on"

Yes, I know the set command is wrong, but what it does is makes *every*
executable file read only and will not allow *any* file to be writen too, so
the only way to upgrade a file is to first delete it and then copy a new one!

The real question is what if the following happens...


A virus waits till a user has write rights to SYS:SYSTEM, and then attaches
itself to a NLM! stream.nlm or clib would be a good start! They are the
libraries for netware, then once the virus is active, on the server now, not
the workstation, it can do ANYTHING! From a NLM, you can delete, trash
anything even if it has read only rights!

I believe that the new trend of viruses will be for netware (this is my
opinion!) as NLM infectors!

                -Kam  (^8*

------------------------------

Date:    Wed, 14 Apr 93 19:24:00 +0100
From:    [e-mail] (Robert Hoerner)
Subject: Re: Proffesional Group Virusized ! (PC)

Hello Vesselin,

 VB> Uh, wait a minute... Mich uses INT 1Ah to get the current date, so it
 VB> usually does not trigger on XTs... Or did yours have some kind of CMOS
 VB> clock?

On XTs it is (has been) common practice to insert the commands "date" and "
time" into the autoexec.bat. INT 1Ah will give the system-date as set by the
user. No CMOS is needed (but highly preferred :-))

Ciao, und viele Gruesse,
      Robert

- ---
 * Origin: Virus Help Service Karlsruhe, 49-721-821355 (9:492/2170)

------------------------------

Date:    Wed, 14 Apr 93 13:25:00 +0100
From:    [e-mail] (Sten Drescher)
Subject: Re: ANSI viruses and things that go bump in the night (mostly PC)

From: [e-mail] (Sten Drescher)

On 6 Apr 93 19:50:08 GMT, [e-mail] (A. Padgett Peterson)
said:

 Padgett> a) If you have the stock ANSI.SYS loaded, have demonstrated
 Padgett> that it is possible to construct a mechanism that will cause
 Padgett> an infection to occur on execution of a DIR command on a
 Padgett> "prepared" floppy.
        Agreed.

 Padgett> b) There is no real need for anyone to have ANSI.SYS loaded.
        Well, yes, no need for the DOS ANSI.SYS.

 Padgett> IMHO while ANSI.SYS once had a real value for key redirection,
 Padgett> this is no longer true. Today the main reason is to set the
 Padgett> screen colors (a PROMPT string containing <esc>[37;44m will
 Padgett> produce a blue background with white letters). You can do the
 Padgett> same thing with a one byte change to COMMAND.COM (DOS 5.0 and
 Padgett> 6.0 COMMAND.COM contain on byte pair "B7 07".  The second byte
 Padgett> defines the screen colors on a CLS (07 is low white on black).
 Padgett> Using DEBUG you can change this byte (found at DEBUG offset
 Padgett> 4A53 in DOS 6.0) to 17 for a blue background or 0F for bright
 Padgett> white on black - - nice on older laptops - Note: you will need
 Padgett> to reboot after the change & COMSPEC must point to the new
 Padgett> COMMAND.COM.
        Hmmmmmm.  Now, tell me, how does this patch allow me to change
screen colors in my PROMPT string?  Answer: it doesn't.  A better
answer, rather than to tell people to make binary patches to their OS,
is to use one of the multitude of ANSI drivers that don't support, or
allow you to disable, key redirection.  Just off the top of my head I
can think of NANSI, NNANSI, ZANSI, ANSIPlus, and ANSI.COM (from PC Magazine).
- - --
+---------------------------+--------------------------------------------+
| Sten Drescher             | "Jill's fourth grade class raised $200     |
| 2709 13th St #1248        |  from a bake sale to reduce the federal    |
| Brooks AFB, TX 78235-5224 |  deficit.  If the deficit is $4 trillion,  |
|---------------------------+  how many bake sales will they need to pay |
| [e-mail]  |  for a $30,000 jogging track?" R Limbaugh  |
+---------------------------+--------------------------------------------+
#include <disclaimer.h>
- --- OD 0.0.1
 * Origin: C.C.C. (9:462/121.0@VirNet)

====> OverDose Gateway Notice <====
Message is actually from [e-mail]
Reply to 9:462/121.0 Internet Gateway with first line of message body beeing:
TO: [e-mail]

------------------------------

Date:    Wed, 14 Apr 93 13:38:06 +0100
From:    [e-mail] (Inbar Raz)
Subject: BeBe Virus (PC)

Hello everyone.

Before you read this letter, you should be aware of the fact that it was not
written at one time. It was written during a research I was (and still) doing.
It will be exported probable before the research is finished, so there might
be more messages, although chances are small.

To the point:

A couple of days ago, I decided to go over the huge virus database I have, and
make it smaller, by removing duplicates, and infecting smaller files whenever
possible.

While doing that, I found a few interesting things:

1. One of the viruses, which I can't remember its name at the moment, tries to
   find the original vector of Interrupt 13h by searching for CMP DL,80 in the
   BIOS segment (0F000h), and therefore it didn't work on my computer - when
   I ran it, I had to load it into the debugger, and actually feed it with a
   vector to Interrupt 13h :-). I later found another virus, Cemetery, which
   is actually a Murphy mutant, which also tries to imply this trick, thus I
   tend to believe that the first one was also a Murphy mutant. However, this
   technique also appears to be used by the Dark Avenger virus, as I later
   found out.

2. The BeBe virus, for some reason, did not execute well. It hung the
   computer. What's more weird is that if I load it to a debugger and STEP it,
   it works. Even more weird is that if I load and GO, it hangs as well.

3. I have a virus, aliased 'Brothers in Arm'. I was very suprised to find that
   only SCAN has managed to find this virus, but even that not completely
   fine. Scan claimed there were both Brothes [Bro] and 1530 [1530]. TBSCAN
   (by ThunderByte) found nothing, as well as PF1's UNVIRUS. When I ran the
   infected program, nothing else ran afterwards - I simply returned to the
   DOS prompt. Even DIR returned nothing.

Any ideas as for the Bebe? The VSUM says that it won't replicate on 386's, but
hang - exactly what happened, but it doesn't say why. I suspect it has to do
with the virus's jmp instruction. The virus does a relocation-like operatin on
a FAR JMP instruction within itself, to jump to the virus code. After that, I
can run the program freely in DEBUG, and, like I said, it
works.

Inbar Raz
- - --
Inbar Raz                  5 Henegev, Yavne 70600 ISRAEL. Phone: [phone]
Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 [e-mail]

- --- FMail 0.94
 * Origin: Inbar's Point - Home of the UnTinyProg. (9:9721/210)

------------------------------

Date:    Sun, 18 Apr 93 11:55:00 +0100
From:    [e-mail] (Amir Netiv)
Subject: "DIR" infection, or "Can internal commands infect" (PC)

[e-mail] (Fridrik Skulason) writes on a reply to
[e-mail] (Amir Netiv)

AN:
 >>unreported). There is a reason for all that: every program that needs more
 >>memory MAY overwrite the TRANSIENT part in memory (so more memory is
 >>available to programs).

FS:
 > Small correction:  Some TSRs may NOT overwrite that
 > part, if they may get called while COMMAND.COM is active.
 > This includes all programs that intercept INT 21, AH=4B,
 > some INT 2FH functions etc...
True. Moreover: *Most* programs will not touch the TRANSIENT, but
the large ones or the ones that allocates in the top of the memory on purpose.
This design is a smart idea to allow more system flexibility, It doesn't mean
that it will always happened.

Regards

* Amir Netiv. V-CARE Anti-Virus, head team *

- ---
 * Origin: <<< NSE Software >>> Israel (9:9721/120)

------------------------------

Date:    Sun, 18 Apr 93 11:40:00 +0100
From:    [e-mail] (Amir Netiv)
Subject: "DIR" infection, or "Can internal commands infect" (PC)

Hello Chris

General comment: In my original article I tried to explain the mechanism of
the "SHELL", meaning the way it's devided and the objectives of each part. I
merely stated a possible
mechanism of how a code might be loaded from a floppy with
no intention.

On a reply to Amir Netiv, Chris Franzen writes:

 > The transient part is never overwritten if you execute
 > an internal command.
Thats true. You might overwrite it if you execute a program or allocate memory
to a program.

 > No. I never saw this happen. You will be unable to force a re-read of
 > the transient part by executing an internal DOS command from the
 > DOS prompt...because the DOS prompt (the internal command processor)
 > is part of the transient part :-)
True again. But consider the possibility that you use "DIR" from whithin a
batch file (that also executes programs) the one prior to "DIR" might be the
one that touched the TRANSIENT. Also what do you think about a program that "
shells" to DOS (running "DIR" from whithin a program), in this case the
TRANSIENT also might have been touched at program load time, and the "shell-
to-DOS" frees the memory for the operation (you see many times the instruction
"Insert diskette with COMMAND.COM..." when running programs that exit to DOS
to do some DOS operations).

 >  AN> In conclusion: If you use a floppy drive system (assuming you've
booted >  AN> from it) and you type "DIR" it is possible (but not likelly)
 >  AN> that the TSR part of COMMAND.COM will try to load the TRANSIENT
 >  AN> part from the infected floppy. However: to infect the TRANSIENT part
 >  AN> alone in such a way that the

CF:
 > No! I would like you to demonstrate this. You will be unable to
 > do that eh?
As I said. It will not happened while typing "DIR" at the DOS prompt, but it
might if you run DIR from a batch file or from a program.

 >  AN> TSR will load exactly what you want is an un-easy task (however
 >  AN> possible), but the *INFECTED* COMMAND.COM should be present at boot
 >  AN> time since the TSR knows the file it is using to refresh the TRANSIENT
 >  AN> by meens of a CHECKSUM generated at first loading. Thus: simply
 >  AN> switching COMMAND.COM to
 >  AN> an infected one (after the system is already booted) will not sufice.

CF:
 > He! Here you say "it's unlikely because the reloaded
 > COMMAND.COM must be the one used when first bootet".
Nop. I say that the command.com expects to find the right part in the file on
the floppy by means of a checksum, but we know how "easy" it is to trick this
way of checking, and BTW, I've seen things happened when you are working with
a floppy based system (no hard disk) and switch floppies like mad, (you've
forgotten what it's like probably).

VB:
 >>> infected, you must execute some viral code. Therefore, the question is
 >>> equivalent to whether you can execute some code by executing the DIR
 >>> command on a floppy.

 >  AN> I think I explained above how you *might* execute some code by "DIR".
CF:
 > No. Demonstrate this! Demonstrate this!
Nicely stated. (I can almost here you shout... Goog humor!)
I'd live this to the virus writers to do, They might pick your challange.

 > You will not be able to force a COMMAND.COM- reload if you execute
 > DIR from a plain vanilly DOS prompt.
As expressed before...

 > Hot for reply
Come to Israel, we have 35 deg.cent. today...

Regards

* Amir Netiv. V-CARE Anti-Virus, head team *

- ---
 * Origin: <<< NSE Software >>> Israel (9:9721/120)

------------------------------

Date:    Sun, 18 Apr 93 12:20:00 +0100
From:    [e-mail] (Amir Netiv)
Subject: "DIR" infection, or "Can internal commands infect" (PC)

Vesselin Bontchev writes back to Amir Netiv:

VB:
 > [excellent description deleted]
Thanks.

VB:
 > COMMAND.COM computes a checksum of the transient part and verifies
 > it each time it displays the prompt. That is, after each program
 > termination. EXTERNAL program. Any program can destroy the transient
 > part of the command interpreter, but it will be reloaded right after this
 > external program terminates.
So far so good.

 > During the reload, the checksum will be re-computed and DOS will keep
 > insisting that you supply the real thing until the checksum matches.
Right again, do you not see the possible hole here?

 > That's why you cannot use a different version of the command interpreter,
 > even if you change COMSPEC to point to it. (You CAN use a different
 > -copy- of the same command interpreter, located somewhere else,
 > if you change the COMSPEC variable.)
When you've booted from a floppy derive, the COMSPEC is A:\COMMAND.COM, (did
you forget the days few people had disks?) so you have to keep handy *THE*
bootable floppy.

 > However, the DIR command is internal and its execution
 > does NOT destroy the transient part of COMMAND.COM, therefore
 > it NEVER causes its reloading.
Absolutelly, and definitely TRUE. But what about "DIR" from whithin a program?
The only question here is only: when can you replace the command.com to cause
the reload of the TRANSIENT to load the infected one?

AN:
 >> However: to infect the TRANSIENT part alone in such a way
 >> that the TSR will load exactly what you want is an un-easy task (however
 >> possible), but the *INFECTED* COMMAND.COM should be present at boot time
 >> since the TSR knows the file it is using to refresh the TRANSIENT by
 >> meens of a CHECKSUM generated at first loading.

VB:
 > That's true, but we are talking about the DIR command
 > performing this.
 > It it IMPOSSIBLE.
When you do a "DIR" from whithin a program (with "exec") you load another copy
of command.com do to it, this might be the time when a "simple" does more then
the user expects.

AN:
 >> Thus: simply switching COMMAND.COM to an infected one (after the system is
 >> already booted) will not sufice.

 >> My conclusion is also that it is not possible (in normal conditions) to
get >> infected just by typing "DIR".
See.....

VB:
 > It is not possible under any conditions (ANSI stupidities excluded).

VB:
 > I challenge you to describe me a reproducible
 > situation in which executing the internal DIR command (on an
 > uninfected system and no ANSI keyboard programmability) will cause
 > reloading of the command interpreter from the diskette that is being
 > examined.

I just did, and I leave the rest for virus writers who might pick your
challange.

Regards,

* Amir Netiv. V-CARE Anti-Virus, head team *

- ---
 * Origin: <<< NSE Software >>> Israel (9:9721/120)

------------------------------

Date:    Tue, 20 Apr 93 08:46:58 -0400
From:    Garry J Scobie Ext 3360 <[e-mail]>
Subject: Re: Single state machines and warm reboots (PC)

> From:    [e-mail] (A. Padgett Peterson)
>
> Several people have mentioned the ability of some viruses to survive
> warm reboots and suggested that only cold (power off) reboots be used.
>
> In fact what is happening is that the virus has intercepted the keyboard
> handler and is simulating a warm reboot rather than actually executing
> one. I know of no virus (and am sure will be corrected if wrong 8*) that
> can survive a *real* warm reboot.


Was this thread ever followed up. In Volume 5 Issue 41 1992, Vesselin
noted that no virus could survive the genuine or *real* Ctrl-Alt-Del
or warm re-boot. However, in Issue 44 David Chess notes:

>An interesting argument (we can take it offline if you like; I'd
>claim that there are viruses that can do it in virtually any
>configuration), BUT not of interest to end users.  As far as the user
>is concerned (and that includes even us expert-types when we're
>actually using machines!) if there are -some- viruses that can -
>sometimes- survive a three-key reboot, it's safest to assume that any
>virus might, and to always do a poweroff reboot if it's important to
>have the machine in a clean state.  It's just too easy to make a
>mistake otherwise!  So, to present an alternative to your statement:
>
>  In short, since some viruses ARE able to survive the Ctrl-Alt-Del
>    sometimes,

Was this taken off-line and resolved? David, Vesselin?

Cheers

Garry Scobie LAN Support Officer Edinburgh University Computing
Services e-mail: [e-mail]

------------------------------

Date:    20 Apr 93 14:26:09 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: DOS 6.0 and Scan (McAfee) Interaction (PC)


[e-mail] (Donald Gingrich) writes:

>1. he booted the machine with the MS DOS 6.0 VSAFE in the autoexec (config?)
>   (I haven't seen DOS 6.0 yet)
>2. he ran McAfee scan with the /chkhi option twice (don't ask why)
>3. on the second pass it reported the "filler" virus
:
:
>I believe that these false positives are a combination of both the OS and the
>BIOS.

Huh ?

No...it is much more likely that this is just a signature left in memory by
another anti-virus program...most of us producing anti-virus software try
to be compatible, and not cause false alarms for each other - but there are
a few companies that don't give a $#%%$# if their anti-virus program leave
virus search strings in memory, which may cause other programs to produce
false positives....this is starting to go on my nerves...I just hope they
get at least as many support calls because of this as I do.

Ah, well....back to work... :-)

- -frisk


- --
Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

------------------------------

Date:    Tue, 20 Apr 93 11:52:10 -0400
From:    James Ford <[e-mail]>
Subject: New files on risc (PC)

The following files have been uploaded to risc.ua.edu (130.160.4.7) in
the directory /pub/ibm-antivirus.

               tbav600.zip
              tbavx600.zip

Description follows:
- -----------------------------------------------------------
A new version of the ThunderByte antivirus utilities has
appeared, some major modifications are involved, including
the fact that it has its own virus signatures now.
This to replace the old tbav5xx files (the vsig9303 file
is still useful for htscan19, or for build-it-yourself
things perhaps). Validate info on the new .zips follows;
the "x" version has processor optimized executables for
registered users only (I'm not sure you'd want that, but
it's not that big); oh, and it needs the new pkunzip v2.04.

_filename_    _size_  _date_     _v1_  _v2_
tbav600.zip  267,999  4-15-1993  832E  0C0D
tbavx600.zip  75,811  4-15-1993  2E51  12B5


------------------------------

End of VIRUS-L Digest [Volume 6 Issue 68]
*****************************************